Computer-based collective intelligence recommendations for transaction review

ABSTRACT

In an embodiment, a data processing method comprises obtaining a plurality of first transaction data items for a proposed online credit card purchase transaction that has been recommended for review; obtaining a plurality of second transaction data items for a set of similar past online credit card purchase transactions, wherein each member of the set has one or more transaction feature values that are similar to the transaction data items of the proposed online credit card purchase transaction, and a decision value specifying whether the member was accepted or rejected by a reviewer; obtaining a stored data model of features, feature values, transaction acceptance decisions and rejection decisions of the reviewer based at least in part on the set, determining, based on applying the first transaction data items to the stored data model and a subsequent query to the database among more recent transactions that were not included during model construction, a likelihood value of a particular decision of whether the proposed online credit card purchase transaction would be accepted or rejected by the reviewer of the merchant; causing the likelihood value to be displayed; wherein the method is performed by one or more computing devices.

FIELD OF THE INVENTION

The present invention relates to review of transactions.

BACKGROUND OF THE INVENTION

As the ways in which consumers may purchase goods and services usingcredit cards, debit cards, or other online payment mechanisms bothincrease in number and convenience, the opportunities for fraudulenttransactions to cost merchants (and ultimately, consumers) alsoincreases. Many merchants use one or more validation tools to attempt toidentify fraudulent orders prior to completing a transaction. Thesevalidation tools may be considered part of a risk management pipeline inwhich an order enters the pipeline and retained revenue exits thepipeline.

After receipt of an online order, the order usually is queued forautomated screening. The automated screening may immediately reject someorders, and may send other orders further down the pipeline for manualreview. This manual review represents a profit leak from the pipeline inlabor costs. In some cases, human reviewers may spend eight minutes ofreview time per order or more. Labor costs may account for over half ofthe typical merchant's fraud management budget.

Orders sent to manual review are either accepted or rejected; fraudulentorders that are incorrectly accepted as genuine add to fraud losses, andlegitimate orders that are incorrectly flagged as fraudulent representlost sales and potential loss of customer goodwill. Automated screeningthat properly invokes the manual review process for the fewest number oforders, while still correctly flagging the pool of fraudulent orders,will help plug leaks in the risk management pipeline. Similarly, bettertools to aid the reviewer in the manual review process will directlylower labor costs for merchants, and increase the probabilities ofaccepting genuine orders and rejecting fraudulent orders.

The approaches described in this section are approaches that could bepursued, but not necessarily approaches that have been previouslyconceived or pursued. Therefore, unless otherwise indicated, it shouldnot be assumed that any of the approaches described in this sectionqualify as prior art merely by virtue of their inclusion in thissection.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example, and not by wayof limitation, in the figures of the accompanying drawings and in whichlike reference numerals refer to similar elements and in which:

FIG. 1 illustrates a hierarchical decision tree.

FIG. 2 illustrates constructing a hierarchical decision tree.

FIG. 3 illustrates determining a recommendation for a transaction underreview.

FIG. 4 illustrates a computer system for transaction review.

FIG. 5 illustrates a transaction review as part of a transaction fraudscreening service.

FIG. 6 illustrates computer logic for transaction review.

FIG. 7 is a block diagram that illustrates a computer system upon whichan embodiment of the invention may be implemented.

DETAILED DESCRIPTION OF THE INVENTION

In the following description, for the purposes of explanation, numerousspecific details are set forth in order to provide a thoroughunderstanding of the present invention. It will be apparent, however,that the present invention may be practiced without these specificdetails. In other instances, well-known structures and devices are shownin block diagram form in order to avoid unnecessarily obscuring thepresent invention.

General Overview

In an embodiment, a data processing method comprises obtaining aplurality of first transaction data items for a proposed online creditcard purchase transaction that has been recommended for review;obtaining a plurality of second transaction data items for a set ofsimilar past online credit card purchase transactions, wherein eachmember of the set has one or more transaction feature values that aresimilar to the transaction data items of the proposed online credit cardpurchase transaction, and a decision value specifying whether the memberwas accepted or rejected by a reviewer; obtaining a stored data model offeatures, feature values, transaction acceptance decisions and rejectiondecisions of the reviewer based at least in part on the set;determining, based on applying the first transaction data items to thestored data model, a likelihood value of a particular decision ofwhether the proposed online credit card purchase transaction would beaccepted or rejected by the reviewer of the merchant; causing thelikelihood value to be displayed; wherein the method is performed by oneor more computing devices.

As context, certain embodiments may be used in online transactionsrelating to the purchase of goods and services by credit card, in whicha customer initiates an order or other transaction using an onlinefacility provided by a merchant. The customer order is represented intransaction data stored in a merchant computer. Transaction data iscommunicated electronically by the merchant to a networked transactionreview service that is configured to provide transaction reviewservices. A reviewer, associated with the merchant or the transactionreview service, can use a computer terminal to review the details oftransactions that the computer has recommended for review as potentiallyfraudulent. A transaction may be recommended for review after triggeringon one or more decision rules set by the merchant. For example, atransaction review may be initiated when a fraud score exceeds amerchant's threshold value.

At a modeling computer, data items are collected related to a proposedonline credit purchase transaction that has been recommended for review.A set of similar past online credit purchase transactions areidentified. Each member of the set has one or more transaction featureshaving transaction feature data values that are similar to thetransaction data items of the proposed online credit purchasetransaction, and a decision value specifying whether the member of theset was actually accepted or rejected by a reviewer after review.

The modeling computer stores a data model in memory representingtransaction features, transaction feature values, transaction acceptancedecisions and rejection decisions that the reviewer could perform or didperform, based at least in part on the set of similar transactions.

In an embodiment, the data model is used to automatically determine alikelihood value representing a particular decision of whether theproposed online credit card transaction would be accepted or rejected bythe reviewer of the merchant if the reviewer actually reviewed thetransaction data.

In an embodiment, the data model is used to determine a subset oftransaction features used to define “similarity” for the currenttransaction under review.

In an embodiment, the data model is a decision tree represented by anXML file. Each node in the decision tree has one or more attributes,such as the number of rejected and accepted transactions taken from aportion of a database containing historical transactions used toconstruct the model.

In an embodiment, the database is queried to obtain transaction data,which when combined with the decision tree, determines a likelihoodvalue. The likelihood value is displayed to the reviewer on thereviewer's computer display as additional information for the reviewerto consider while making a decision whether to accept or reject theproposed online credit card transaction.

In an embodiment, the transaction features, transaction feature values,transaction acceptance decisions and rejections decisions of stored datamodel may be associated with past transaction acceptance decisions andrejections decisions of one or more reviewers identified as possessingsuperior decision-making abilities. In an embodiment, the stored datamodel may be rendered in computer memory in the form of a decision treein part by selecting a subset of relevant features from the set offeature data comprising each transaction. For example, there may betransaction features in the stored data model that ultimately areunimportant or not used in reaching a result for a particulartransaction, and such unnecessary elements of the model may be omittedfrom the decision tree. In an embodiment, the subset of relevantfeatures populates the decision tree using hierarchical featureselection.

Credit Transaction Information

Many types of data are captured as part of a proposed online credittransaction and may be made available to a reviewer. As used herein,each type of data is termed a feature, such that each proposedtransaction and historical transaction is a collection of data values,with one data value corresponding to one feature. Examples of featuresinclude:

-   -   1. Name or type of fraud scoring model that is used to score a        transaction;    -   2. Country identified in a billing address for the customer;    -   3. Country identified in a shipping address for the transaction;    -   4. Fraud score;    -   5. One or more Decision rules that triggered the manual review;    -   6. One or more Factor codes, described below;    -   7. One or more Information codes, described below;    -   8. Merchant identifier uniquely identifying a merchant of the        goods or services involved in the transaction;    -   9. Name, number or other identifier of the reviewer;    -   10. Organization that is performing the review.

In this context, a Factor code represents groupings of contributions tothe risk level of the transaction. For example, a Factor code of “v” mayrepresent a high velocity risk related to the transaction, in whichidentity information included in the transaction is repeated multipletimes. A Factor code of “c” may represent an increase risk level becauseof multiple account changes appearing in the history of the transaction.

In this context, an Information code represents individual anomaliesfound within the transaction and which may indicate a higher risk level.For example, one Information code may indicate use of a free e-mailaddress used in the transaction, or that multiple different e-mailaddresses appear in the history of the transaction. Another Informationcode may indicate repeated use of the credit card used in thetransaction during the past 15 minutes in other transactions.

In a simplified example, a sample historical transaction may include thefollowing data values for the following corresponding features: {US(country of billing), CA (country of shipping), 60-70 (score range), H(factor code), VEL_ADDR (information code), 336577 (merchantidentifier)}. Additionally, a sample historical transaction may includeother information indicating the review history of the transaction. Inan embodiment, data values may indicate the following history regardingthe transaction:

-   -   1. the transaction was immediately accepted or rejected;    -   2. the transaction was accepted or rejected after further        automatic review; or    -   3. the transaction underwent manual review, the acceptance or        rejection decision of the reviewer, and an identifier        identifying the reviewer.        In an embodiment, a decision of the manual reviewer may have        values of either “accept” or “reject.”

An actual proposed transaction or an actual historical transaction mayhave data values for over 60 features. Even if each feature has only afew possible data values, the total number of possible uniquetransactions grows exponentially. For example, if a transactioncomprises 60 features, and each feature may take on one of threepossible data values, the number of possible unique transactions is 3̂60,or approximately 4.23×10̂28 transactions. Therefore, it may beimpractical to store, in computer data storage capable of retrieval orreview in a reasonable time, all features of all transactions.Additionally, as more transaction features are used to determinesimilarity among transactions, the number of actual transactions thatsatisfy the similarity criteria becomes too small from which to form amodel. Thus feature selection described below is performed to locate asubset of features. The approaches herein provide the benefit ofcapturing an association of reviewer decisions to characteristics ofhistoric transactions, for use in predicting reviewer decision oncurrent transactions, without the need to store all features of allhistoric transactions.

A decision tree based on a data model of historic transactions need notinclude all features of the historic transactions. In the discussion ofconstruction of a sample data model below, example transaction featuresthat may be used in construction of a hierarchical decision tree as partof an embodiment are further described.

Sample Model Construction—Top Nodes

In an embodiment, creating and storing the stored data model may resultin creating and storing a hierarchical decision tree. In an embodiment,one pre-determined transaction feature is associated with a root node ofthe decision tree. The root node corresponds to a top-most decision ruleto be applied to data values of a first transaction feature. A selectedset of child nodes associated with corresponding transaction featuresare also pre-determined.

FIG. 1 illustrates a hierarchical decision tree. In FIG. 1, hierarchicaldecision tree 100 represents transaction features as nodes, and eachbranch from a node corresponding to the path traveled based on the datavalue of the transaction feature. Any transaction feature appearing inhierarchical decision tree 100 is represented as one or more nodes ofhierarchical decision tree 100. The illustration in FIG. 1 is notintended to depict a complete hierarchical decision tree 100 but ratherto provide a representative portion.

In hierarchical decision tree 100, transaction features that are morediscriminating in predicting a likelihood of accepting or rejecting atransaction under review are represented as nodes closer to the root ofhierarchical decision tree 100 than transaction features that are lessdiscriminative. In hierarchical decision tree 100, a subset oftransaction features have been preselected for use at the top levels ofhierarchical decision tree 100. Alternatively, determining and selectingthe subset of transaction features, which are more discriminating, couldbe performed using the methods described below for the determination ofsub-trees. In hierarchical decision tree 100, the top levels ofpreselected transaction features correspond to the following transactionfeatures: Merchant Identifier (root), Model Used (first level), Countryof Billing (second level), and Score Range (third level). Otherpreselected transactions may be included in the model, but are notillustrated here for clarity. For example, in an embodiment, the one ormore Decision rules that trigger manual review may appear as apreselected transaction feature appearing on the fourth level ofhierarchical decision tree 100.

Merchant ID 102 is the transaction feature at the root node ofhierarchical decision tree 100, and paths downward from the root nodeare determined by the data value of Merchant ID 102. If there are “n”unique values corresponding to a total of “n” possible merchants, edge104 may represent deciding that the transaction is for the firstmerchant, and edge 106 may represent deciding that the transaction isfor the n-th merchant; for example, the data value of Merchant ID 102representing the first merchant may be “ACME.” For ease of illustration,paths following edge 106 are not illustrated. In FIG. 1, “n” edges leavethe root node, even though only edge 104 and edge 106 are illustrated.

Model Used 108 is the transaction feature appearing at the first levelof hierarchical decision tree 100. As illustrated, edge 110 mayrepresent the decision made for the data value of “default” value forModel Used 108. Thus, edge 110 is directed towards features that wereconsidered for historical transactions that were scored using a defaultfraud scoring model.

Billing Country 112 is the transaction feature appearing at the secondlevel of hierarchical decision tree 100. As illustrated, edge 114 mayrepresent the decision made for the data value of “US” for BillingCountry 112. Thus, nodes below edge 114 represent tests and decisionsfor historic transactions for which the billing address was in theUnited States.

Score Range 116 is the transaction feature appearing at the third levelof hierarchical decision tree 100. The Score Range 116 is used todiscriminate among the fraud score value that was assigned to atransaction by a separate fraud scoring engine of the merchant or from aservice provider. In this example, a transaction's fraud score value mayrange from zero to 100, and the transaction's score value is placed inone of “k” preselected intervals that comprise the complete range. Forexample, edge 118 may represent the decision made for the data valuefalling within the range of zero to ten for Score Range 116(corresponding to the first interval in the complete range). Edge 122may represent the decision made for the data value falling in the rangeof 96 to 100 for Score Range 116 (corresponding to the k-th interval inthe complete range).

Sub-tree_(—)1 120 is the transaction feature appearing at the fourthlevel of hierarchical decision tree 100, in which there are a total of“m” sub-trees at the fourth level of hierarchical decision tree 100.Thus, if the final determination to be made for a candidate transactionis a descendent of sub-tree_(—)1 120, then the candidate transactionmust have at least the following transaction feature values:

{Merchant ID =“ACME”, Model Used= “default”, Billing Country= “US”,Score Range= “0-10”}.

Sample Model Construction—Sub-Trees

In FIG. 1, a subset of transaction features have been preselected foruse at the top four levels of hierarchical decision tree 100. In otherembodiments, transaction features are preselected from level zero to anarbitrary level. Thus, for example, in an embodiment, no transactionfeatures are preselected, and hierarchical decision tree 100 isdetermined using the construction of sub-trees, described here and withrespect to FIG. 2.

In an embodiment, the set of candidate features comprise featurescorresponding to factor codes and information codes. In an embodimenteach factor code and information code candidate feature may only take onvalues of one (corresponding to “fired”) and zero (corresponding to “notfired.”)

In an embodiment, the process of FIG. 2 is performed on a modelingcomputer for each sub-tree whose ancestors' nodes correspond topreselected transaction features. For example, FIG. 1 has “m” sub-treesat the fourth level of hierarchical decision tree 100, beginning withsub-tree_(—)1 120, and FIG. 2 is performed first with respect tosub-tree_(—)1 120. The steps of FIG. 2 are then performed with respectto the second sub-tree at the fourth level of hierarchical decision tree100, and then repeated with respect to the third sub-tree at the fourthlevel of hierarchical decision tree 100. This procedure is repeateduntil completed on the last (m-th) sub-tree at the fourth level ofhierarchical decision tree 100.

At step 202, the modeling computer determines the set of availablecandidate features used to construct nodes in the sub-tree comprises allcandidate features, minus any pre-selected candidate features. Forexample, with reference to FIG. 1, the set of all candidate features forsub-tree_(—)1 120 comprises all candidate features, minus thepreselected candidate features Merchant ID 102, Model Used 108, BillingCountry 112, and Score Range 116.

At step 204, zero or more features from the set of available candidatefeatures are removed from the set of available candidate features. Theremoved features are not used in sub-tree construction because the datavalues corresponding to the removed features have little or noassociation with the class variable DM_RESULT (corresponding to adecision result) taking on the value “reject”, and thus inclusion of theremoved features into the model would not increase the discriminationpowers of the model.

In an embodiment, a feature is removed based on an association betweenthe data values of the removed feature and the transaction data forwhich DM_RESULT equals “reject.” In an embodiment, the feature isremoved when the absolute value of the calculated association is lessthan a preselected value. In an embodiment, the association isquantified by statistical lift, that is a ratio between the probabilityof DM_RESULT=“reject,” given the feature takes on the value, and theprobability of DM_RESULT=“reject,” given the feature does not take onthe value.

At step 206, the set of available candidate features is compared, andfeatures whose data values are highly associated are combined. In anembodiment, each possible pairwise correlation among data values of eachpossible pair of available candidate features is calculated. In anembodiment, a pair of available candidate features is combined when theabsolute value of the calculated correlation is greater than apreselected value.

Once a pair of available features whose data values are highlyassociated is determined, each feature of the pair of available featuresis removed from the set of available candidate features, and singlecombined candidate feature representing the pair of features is added tothe set of available candidate features. In an embodiment, patternsother than pairwise association may be used to combine candidatefeatures.

For example, if the set of available candidate features comprises thefeatures MORPH_FP, MORPH_FE, MORPH_FC, and MORPH_FS, and availablefeatures {MORPH_FP=1} and {MORPH_FS=1} are highly associated, theresulting set of available candidate features becomes MORPH_FE,MORPH_FC, and MORPH_FP-MORPH_FS, in which combined available featureMORPH_FP-MORPH_FS is a combination of features MORPH_FP and MORPH_FS.Similarly, if {MORPH_FP=1, MORPH_FE=1, MORPH_FC=1} is mined to be afrequent pattern, the resulting set of available candidate featuresbecomes MORPH_FS and MORPH_FP-MORPH_FE-MORPH_FC.

In an embodiment, data values for the combined available feature aredetermined based on the data values for each feature used to form thecombined available feature. In an embodiment, data values for thecombined available feature are set equal to the data values of one ofthe two available features used to form the combined available feature.In an embodiment, each feature of the pair of available features takeson data values of zero or one, and data values for the combinedavailable feature are set equal to the logical “or” value of the datavalues of the pair of the available features used to form the combinedavailable feature.

Evaluation of the stopping criteria at step 208 is discussed below afterdiscussion of step 212. If the stopping criteria are satisfied, then theprocedure terminates at step 210.

At step 212, a feature from the set of remaining available/combinedfeatures is selected as the splitting node to be added to the sub-tree.In an embodiment, each splitting node is determined using a contingencytable calculated for each candidate feature from the set of remainingavailable/combined features. A contingency table is constructed usingthe set of historical transactions corresponding to the parent node ofthe sub-tree, with this set separated in subsets representing theacceptance or rejection the historical transactions, and separated bythe data values of each candidate feature.

In an embodiment, each candidate feature takes on data values of zero orone. A data value of one corresponds to the “firing” of the candidatefeature, and a data value of zero corresponds to the candidate feature“not firing.” “Firing,” in this context, means that a candidate featurein a particular transaction, which may be a historical transaction, hasa data value of one with respect to a particular outcome for theparticular transaction. For example, the data value to record atransaction in which a particular Information Code corresponds to use ofa free e-mail address may be set equal to one, and the data value torecord a transaction in which the particular Information Code does notcorrespond to a use of a free e-mail address may be set equal to zero.Thus, for all transactions in which the particular Information Codecorresponds to a use of a free e-mail address, the Information codecandidate feature has “fired.” A contingency table for this candidatefeature could appear as follows:

Contingency Table for Candidate Feature Not Fired(=0) Fired(=l) TotalAccepted N₀₀ N₀₁ N₀₊ Rejected N₁₀ N₁₁ N₁₊ Total N₊₀ N₊₁ NFor example, if the contingency table above corresponds to one of theavailable candidate features considered for use as the splitting nodefor sub-tree_(—)1 120, then out of “N” total historical transactionsrepresenting historical transactions that having data values thatsatisfy the parent of sub-tree_(—)1 120, “N₀₀” historical transactionsof the total were accepted when the candidate feature was not fired.Similarly, in “N₁₁” of the rejected historical transactions of thetotal, the available candidate feature was fired. In this context,constructing the contingency table comprises counting transactions fromthe set of historical transactions, and a storing the counts in computermemory in a table data structure, or an equivalent.

Clearly, it is desirable to select the available candidate feature foruse as the splitting node that provides the most information relating toa transaction decision. In an embodiment, a relative entropy measure isused as a selection metric. In an embodiment, the relative entropymeasure is defined as:

relative entropy (RE)=P ₁ log₂(P ₁ /Q ₁)−(1−P ₁)log₂((1−P ₁)/(1−Q ₁)),

where

P ₁ =N ₁₁ /N ₊₁

and

Q ₁ =N ₁₀ /N _(+1,)

In an embodiment, an absolute risk is used as a selection metric. In anembodiment, the absolute risk is defined as:

absolute risk (AR)=(N ₁₁ /N ₊₁)−(N ₁₀ N ₊₀),

In an embodiment, a relative risk is used as a selection metric and isdefined as:

relative risk (RR)=(N ₁₁ /N ₊₁)/(N ₁₀ /N ₊₀),

Each selection metric provides a quantitative measurement that connectsthe historical data regarding an available candidate feature to thefinal determination made regarding whether to accept or rejecttransaction in each transaction comprising the historical data.

In an embodiment, the selected candidate feature selected for use as thesplitting node from set of remaining available features or combinedfeatures is the available candidate feature having the largest relativeentropy value. When a splitting node is selected, the splitting node isstored in memory as part of the tree at a current node position.

In an embodiment, when the difference of the two available candidatefeatures having the two largest relative entropy values is within apreselected value, the selected candidate feature selected for use fromthe pair is the available candidate feature having the higher firingrate.

After the selected candidate feature has been selected in step 212, atstep 214 the selected candidate feature is removed from the set ofremaining available/combined features and the stopping criteria areevaluated at step 208. Steps 208-214 are performed recursively so thateach branch of a sub-tree is completely constructed prior to attemptingto construct another branch from the parent of the sub-tree.

A variety of criteria may be used in step 208 to determine thetermination of a branch of sub-tree. In an embodiment, terminationoccurs when the value of “N” described above is less than a preselectedvalue, e.g., the number of total transactions is less than 20. In anembodiment, termination occurs when the accept rates for each of theremaining available/combined candidate features are within a preselectedvalue of one another. In an embodiment, termination occurs when therejection rates for each of the remaining available/combined featuresare within a preselected value of one another.

In an embodiment, termination occurs when the largest value of therelative entropy is less than preselected positive value. For example,if all values in the contingency table are equal to the value “n,” thenthe contingency table has the contents:

Contingency Table for Candidate Feature that Provides No Information NotFired Fired Total Accepted n n 2n Rejected n n 2n Total 2n 2n N = 4n

Then P ₁ =N ₁₁ /N ₊₁=1/2

and

Q ₁ =N ₁₀ /N ₊₀=1/2,

and

RE equals P ₁ log₂(P ₁ /Q ₁)−(1−P ₁)log₂((1−P ₁)/(1−Q ₁)),

or ½ log₂(1)−(1−1/2)log₂((1−1/2)/(1−1/2)),

which equals zero.

In a contingency table in which all measured data values for a candidatefeature under the combinations {Accepted/Not Fired, Accepted/Fired,Rejected/Not Fired, Rejected/Fired} have the same value of “n,”incorporation of this candidate feature into the model adds no newinformation, as the value of the candidate feature provides no morefurther statistical connection to the acceptance or rejection of thetransaction.

Sample Transaction Review Using Hierarchical Decision Tree

Once all branches of the hierarchical decision tree have beenconstructed, the hierarchical decision tree may be used as part of adecision system. An embodiment of a method of using the hierarchicaldecision tree as part of a decision system is illustrated in FIG. 3.

In step 302, transaction feature values for a transaction under manualreview are obtained. In one embodiment, the reviewing computer obtains,from a transaction management system, a data record for a transactionthat has been flagged or identified as suggested for manual review, andfeature data values are obtained from the record. For example, consideran enlarged version of the transaction described above, having thefollowing transaction features and transaction feature values:

{Merchant ID =“ACME”, Model Used = “default”, Billing Country = “US”,Score Range = “0-10”, VEL_ADDR = 0, MORPH_FP = 0, RISK_AC = 0, RISK_PH =1, INTL_BIN = 0, MUL_EM = 1, MM_EMBCO = 1}.

In step 304, the hierarchical decision tree is traversed using data forthe transaction under review, to obtain a set of “neighbors” of thetransaction under review that share the set of transaction featurevalues. For example, traversal involves starting at a root node of thedecision tree, determining what feature the node represents, finding thevalue for that feature in the data for the transaction under review, anddetermining which edge to follow based on the value in comparison to adecision represented in the node. Following an edge leads to a next nodeat which the process is repeated for another feature, until a terminalnode of the tree is reached. The terminal node is associated withidentifiers for other historic transactions having all the sametransaction feature values that led to that terminal node; thesehistoric transactions are neighbor transactions, and each such neighbortransaction has an associated decision value representing a reviewer'sactual historic decision for that transaction.

In step 306, the number of neighbors, that is the number of transactionsin which the reviewer decision is “reject” and the number oftransactions in which the reviewer decision is “accept,” is obtained.Each of the number of “reject” transactions and the number of “accept”transactions is an attribute of the stored data model, with thetransaction numbers obtained by querying the database for databasetransactions occurring over a recent period. In an embodiment, thetransaction numbers reflect a period of 18 months. In an embodiment, thedata comprising the transaction numbers is not used to construct thehierarchical decision tree.

The number of neighbors is compared to a threshold value in step 308. Inan embodiment, the threshold value is set to a fixed value; for example,the threshold value may be set to 20. In an embodiment, the thresholdvalue is a function of one or more termination values used in theconstruction of the hierarchical decision tree. The threshold valuerepresents whether the number of neighbors is large enough to provide anadequate basis for predicting a decision of a reviewer for the currenttransaction under review.

If the number of neighbors of the transaction under review exceeds thethreshold value, then in step 312, the overall reject rate among theneighbors is obtained. For example, for the example transaction shownabove, suppose the number of neighbors is 40, in which 10 transactionswere rejected and 30 transactions were accepted. The reject rate is then10/40, or 25%. In step 314, the reject rate is converted into arecommendation.

In an embodiment, the recommendation is the reject rate. Thus, in anembodiment, a user of the decision system would receive a messageindicating that in a database of historical transactions, transactionssimilar to the transaction under review were rejected 25% of the time.

However, the number of neighbors for a transaction under review may besmall, or even zero, should the transaction under review correspond to asparsely populated portion of the hierarchical decision tree. Thus instep 308, should the number of neighbors be less than the thresholdvalue, in step 310, the last feature of the transaction under review isdropped to, to enlarge the neighborhood of similar transactions underreview. Control resumes at step 306 using the enlarged neighborhoodunder review.

For example, should the number of neighbors of the sample transaction:

{Merchant ID =“ACME”, Model Used= “default”, Billing Country = “US”,Score Range = “0-10”, Info_Code1 = 0, Info_Code2 = 0, Info_Code3 = 0,Info_Code4 = 1, Info_Code5 = 0, Info_Code6 = 1, Info_Code7 = 1}be less than the threshold value, the feature Info_Code7 is removed, andthe modified transaction:

{Merchant ID =“ACME”, Model Used= “default”, Billing Country = “US”,Score Range = “0-10”, Info_Code1 = 0, Info_Code2 = 0, Info_Code3 = 0,Info_Code4 = 1, Info_Code5 = 0, Info_Code6 = 1}is used as the input for step 306.

In an embodiment, should the number of neighbors be less than thethreshold value, the historical transaction database is queried over alonger period to obtain a larger number of transactions that comprisethe number of “reject” transactions and the number of “accept”transactions of the stored data model.

In an embodiment, the database of transaction data includes a historicalportion of the database comprising transaction data used to constructthe hierarchical decision tree, and a portion of the database containingtransaction data collected after construction of the hierarchicaldecision tree. In an embodiment, the number of neighbors for a sampletransaction is determined for both database portions. In an embodiment,more weight is given to decision results corresponding to manual reviewdecisions made after construction of the hierarchical decision tree.This is described further below with reference to FIG. 5.

Sample Transaction Review System

An embodiment of a transaction review system is illustrated in FIG. 4.Transaction review system 400 comprises database 402, server 404,modeling computer 406, hierarchical decision tree 408, and reviewterminal 410.

Database 402 contains online transaction data used to constructhierarchical decision tree 408 that is consulted during the manualreview of a proposed online transaction. Database 402 may be externalto, and connected to, server 404. In an embodiment, database 402 resideson server 404.

Database 402 periodically accepts transaction data from actual onlinetransactions. Transaction data may be accepted from one or more of thefollowing sources, such as external disk drives, flash drives, read-onlyor random access memory, or via one or more network connections. In anembodiment, database 402 may separate historical data transactions, thatis, transaction action data used to form hierarchical decision tree 408available to manual reviewers, from more current transaction data to beused to update current models or create new models.

Server 404 contains computer executable software or hardware code usedto create and maintain one or more hierarchical decision trees, and toprovide a user interface for transaction review system 400 throughmodeling computer 406 for an administrator of transaction review system400. Server 404 also contains computer executable software or hardwarecode used to calculate summary statistics for transaction data indatabase 402. In an embodiment, transaction data in database 402 may beorganized by reviewer, so that hierarchical decision tree 408 may beconstructed from historical transaction data from a selected set of oneor more reviewers, thus providing a manner to ‘clone’ the knowledge andexpertise of one or more talented reviewers.

In an embodiment, each hierarchical decision tree 408 created usingtransaction review system 400 is represented in one or more XML files.In an embodiment, each hierarchical decision tree 408 is stored inserver 404. In an embodiment, each hierarchical decision tree 408 isstored in local storage on modeling computer 406.

An example of portion of a hierarchical decision tree encoded using XMLis the following

<merchant_id depth=0 total=3141720 RejectRate=6.60% cardinality=329> <.ACME depth=1 total=177275 RejectRate=5.28%  <model_used  depth=2 total=177275 RejectRate=5.28%   cardinality=l >   <default  depth=3 total=177275 RejectRate=5.28%>    <bill_country depth=4 total=177275 RejectRate=5.28%    cardinality=l >     <us depth=5 total=l7775 RejectRate=5.28%>     <post_data_fusion_score depth=6 total=177275      RejectRate=5.28%cardinality=4>        <0-0 depth=7 total=10280 RejectRate=3.51%>     <UNV_PH depth=8 total=10280 RejectRate=3.51%      cardinality=2FireRate=0.12%>        <depth=9 total=12 RejectRate=8.33%        <leafdepth=10 total=10280 RejectRate=8.33%>        <\leaf>      <\l>      <0depth=9 total=10268 RejectRate=3.51%>        <RISK_PH depth=10total=10268 RejectRate=3.51%     cardinality=2 FireRate=0.12%>        <1 depth=11 total=12 RejectRate=0.00%>          <leaf depth=12total=10268 RejectRate=0.00%>          <\leaf>         <\1>         <0depth=11 total=10256 RejectRate=3.51%>          <VEL_NAME depth=12total=10256          RejectRate=3.51%          cardinality=2FireRate=1.66%          <1 depth=13 total=170 RejectRate=1.76%>          <leaf depth=15 RejectRate=1.76%>           <\leaf>         <\1>          <0 depth=13 total=10086 RejectRate=3.54%>          <leaf depth=15 RejectRate=3.54%>           <\leaf>         <\0>        <\0>    <\0> <\0-0>    <1-29 depth=7 total=76953RejectRate=4.13%>     <VEL_NAME depth=8 total=76953 RejectRate=4.13%     cardinality=2     FireRate=9.68%>      <1 depth=9 total=7450RejectRate=2.19%>       <UNV_PH depth=10 total=7450 RejectRate=2.19%      cardinality=2     FireRate=0.20%>        <1 depth=11 total=15RejectRate=6.67%>         <leaf depth=12 total=7450 RejectRate=6.67%>        <\leaf>        <\1>        <0 depth=11 total=7435RejectRate=2.18%>         <RISK_PH depth=12 total=7435 RejectRate=2.18%        cardinality=2 FireRate=0.27%>          <1 depth=13 total=20RejectRate=5.00%>           <leaf depth=14 total=7435 RejectRate=5.00%>          <\leaf>          <\1>          <0 depth=13 total=7415RejectRate=2.17%>           <leaf depth=15 RejectRate=2.17%>          <\leaf>          <\0>        <\0>      <\1>     <0 depth=9total=69503 RejectRate=4.34%>       <UNV_PH depth=10 total=69503RejectRate=4.34%       cardinality=2 FireRate=0.33%>        <1 depth=11total=228 RejectRate=5.70%>          <leaf depth=13 RejectRate=5.70%>         <\leaf>        <\l>        <0 depth 11 total 69275 RejectRate4.33%>         <RISK_PH depth=12 total 69275 RejectRate=4.33%        cardinality=2 FireRate=0.22%>           <1 depth=13 total=153RejectRate=3.27%>           <leaf depth=15 RejectRate=3.27%>          <\lea£>          <\1>          <0 depth=13 total=69122RejectRate=4.34%>           <leaf depth=15 RejectRate=4.34.%>          <\leaf>          <\0>         <\0>        <\0>      <\1-29>       <\post_data_fusion_score>     <\us>    <\bill_country>  <\default>  <\model_used>  <\ACME> <\merchant_id>

XML offers a convenient and machine-independent representation that iseasily traversed when a transaction under review is processed to providethe manual reviewer a recommendation regarding whether to accept orreject the transaction under review.

Each manual reviewer accesses transaction review system 400 throughreview terminal 410 that is connected to server 404 via one more networkconnections. In an embodiment, each manual reviewer lacks one or moreadministrative functions provided to an administrator who accessestransaction review system 400 through modeling computer 406. Forexample, manual reviewers may not be able to alter hierarchical decisiontree 408 used to provide a transaction recommendation. However, a manualreviewer may provide input to transaction review system 400 for use inrefining current models or building future models. In an embodiment, amanual reviewer may annotate a review decision with one or more reasoncodes or plain text describing one or more transaction data values thatthe reviewer cites as determinative in the reviewer's final transactiondecision. Such information is input at review terminal 410 in additionto the reviewer's transaction decision, and may be further processed byan administrator during model construction.

FIG. 5 illustrates a transaction review as part of a transaction fraudscreening service. At step 502, a transaction for manual review isreceived by transaction review system 400. At step 504, the transactionfeature values for the transaction under review are obtained. Usingthese obtained transaction feature values, hierarchical decision tree408 is traversed until a leaf node is reached.

At step 506, the leaf node is set as the current node.

At step 508, with respect to the historical portion of the database, thedistribution of decision results for manually reviewed transactions atthe current node is obtained, along with the trace used to reach thecurrent node. As a non-limiting example, suppose the number of manuallyreviewed transactions at the current node that (a) are contained in thehistorical portion of the database, and (b) were used in construction ofhierarchical decision tree 408, comprise 10 rejected transactions and 30accepted transactions.

At step 510, the database is queried using the feature values specifiedby the trace to obtain the decision results of manually reviewedtransactions that have not been incorporated into the historical portionof the database. These decision results correspond to manual reviewdecisions made after construction of hierarchical decision tree 408. Forexample, hierarchical decision tree 408 may be constructed on a periodicbasis, such as every 90 days. Thus, if hierarchical decision tree 408was constructed 45 days ago, transaction data for the past 45 days hasnot been placed into the historical portion of the database. Similarly,the transaction data for the past 45 days was not used to construct thecurrent version of hierarchical decision tree 408.

With respect to the non-limiting example, suppose that the number ofmanually reviewed transactions at the current node that (a) are notcontained in the historical portion of the database, and (b) were notused in construction of hierarchical decision tree 408, may comprise 5rejected transactions and 5 accepted transactions. These transactionsoccurred after hierarchical decision tree 408 was constructed.

At step 512, the decision results of manually reviewed transactions fromboth the historical portion of the database and the current portion ofthe database are combined and an effective sample size is obtained. Inan embodiment, weights based on the age of each transaction are appliedto each transaction. For example, more current transactions may receivemore weight than transactions occurring in the past. Use of age-basedweights would give more weight to more recent transaction decisions. Themore recent transaction decisions may themselves result from changingpatterns of fraudulent activity detected among the more currenttransactions.

Using the non-limiting example from above, the total sample sizeobtained by combining the historical portion of the database togetherwith the more recent transactions is 15 rejections (=10 historical+5current) out of a total of 50 transactions (=40 historical+10 current).However, suppose that each historical transaction receives only half theweight of a current transaction for determining the effective samplesize and the rejection rate. Then the effective sample size becomes 10rejections (=5 historical+5 current) out of a total of 30 transactions(=20 historical+10 current).

At step 514, the effective sample size is compared to a threshold value.Should the effective sample size be too small, then at step 524 theparent of the current node is set as the current node, and controlresumes at step 508. If the effective sample size is greater than orequal to the threshold value, then at step 516, a likelihood value isobtained and converted into a recommendation.

Using the current example, suppose the threshold value equals 20, thenthe effective sample size of 30 is sufficient to obtain a likelihoodvalue of 33%, which equals 10 rejections out of a total of 30transactions.

At step 518, the transaction and recommendation are sent to the reviewerfor manual review and decision. At step 520, the reviewer makes adecision, and the transaction, the review's decision, and other feedbackthat may be provided by the reviewer is marked and placed in

FIG. 6 illustrates computer logic for transaction review contained intransaction review system 400. In an embodiment, this computer logic isexecuted on modeling computer 406. Modeling computer 406 has processorinput/output interface 610, processor 618, local storage 620, and logicmodules described below. Modeling computer 406 communicates withdatabase 402 through input/output interface 610 having input 612 andoutput 614. In an embodiment, database 402 contains historical datatransactions 616 that are used by modeling computer 406 to constructhierarchical decision tree 408, and current data transactions 617corresponding to data transactions occurring after hierarchical decisiontree 408 has been constructed.

Modeling computer 406 has logic modules comprising database query logic620, candidate feature selection logic 622, candidate featurecombination logic 624, and splitting node logic 626. Database querylogic 620 queries database 402 to obtain historical data transactions616 used as input data at step 202 of FIG. 2. Candidate feature removallogic 622 performs the removal of features from the set of availablecandidate features, performed at step 204 of FIG. 2.

Candidate feature combination logic 624 performs the combination offeatures from the set of available candidate features having a largeassociation, performed at step 206 of FIG. 2. Splitting node logic 626selects and removes splitting nodes to construct hierarchical decisiontree 408, as performed at steps 208-214 of FIG. 2. In an embodiment,once constructed, hierarchical decision tree 408 is stored in modelingcomputer 406 in local storage 620.

Hardware Overview

According to one embodiment, the techniques described herein areimplemented by one or more special-purpose computing devices. Thespecial-purpose computing devices may be hard-wired to perform thetechniques, or may include digital electronic devices such as one ormore application-specific integrated circuits (ASICs) or fieldprogrammable gate arrays (FPGAs) that are persistently programmed toperform the techniques, or may include one or more general purposehardware processors programmed to perform the techniques pursuant toprogram instructions in firmware, memory, other storage, or acombination. Such special-purpose computing devices may also combinecustom hard-wired logic, ASICs, or FPGAs with custom programming toaccomplish the techniques. The special-purpose computing devices may bedesktop computer systems, portable computer systems, handheld devices,networking devices or any other device that incorporates hard-wiredand/or program logic to implement the techniques.

For example, FIG. 7 is a block diagram that illustrates a computersystem 700 upon which an embodiment of the invention may be implemented.Computer system 700 includes a bus 702 or other communication mechanismfor communicating information, and a hardware processor 704 coupled withbus 702 for processing information. Hardware processor 704 may be, forexample, a general purpose microprocessor.

Computer system 700 also includes a main memory 706, such as a randomaccess memory (RAM) or other dynamic storage device, coupled to bus 702for storing information and instructions to be executed by processor704. Main memory 706 also may be used for storing temporary variables orother intermediate information during execution of instructions to beexecuted by processor 704. Such instructions, when stored in storagemedia accessible to processor 704, render computer system 700 into aspecial-purpose machine that is customized to perform the operationsspecified in the instructions.

Computer system 700 further includes a read only memory (ROM) 708 orother static storage device coupled to bus 702 for storing staticinformation and instructions for processor 704. A storage device 710,such as a magnetic disk or optical disk, is provided and coupled to bus702 for storing information and instructions.

Computer system 700 may be coupled via bus 702 to a display 712, such asa cathode ray tube (CRT), for displaying information to a computer user.An input device 714, including alphanumeric and other keys, is coupledto bus 702 for communicating information and command selections toprocessor 704. Another type of user input device is cursor control 716,such as a mouse, a trackball, or cursor direction keys for communicatingdirection information and command selections to processor 704 and forcontrolling cursor movement on display 712. This input device typicallyhas two degrees of freedom in two axes, a first axis (e.g., x) and asecond axis (e.g., y), that allows the device to specify positions in aplane.

Computer system 700 may implement the techniques described herein usingcustomized hard-wired logic, one or more ASICs or FPGAs, firmware and/orprogram logic which in combination with the computer system causes orprograms computer system 700 to be a special-purpose machine. Accordingto one embodiment, the techniques herein are performed by computersystem 700 in response to processor 704 executing one or more sequencesof one or more instructions contained in main memory 706. Suchinstructions may be read into main memory 706 from another storagemedium, such as storage device 710. Execution of the sequences ofinstructions contained in main memory 706 causes processor 704 toperform the process steps described herein. In alternative embodiments,hard-wired circuitry may be used in place of or in combination withsoftware instructions.

The term “storage media” as used herein refers to any media that storedata and/or instructions that cause a machine to operation in a specificfashion. Such storage media may comprise non-volatile media and/orvolatile media. Non-volatile media includes, for example, optical ormagnetic disks, such as storage device 710. Volatile media includesdynamic memory, such as main memory 706. Common forms of storage mediainclude, for example, a floppy disk, a flexible disk, hard disk, solidstate drive, magnetic tape, or any other magnetic data storage medium, aCD-ROM, any other optical data storage medium, any physical medium withpatterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, NVRAM, anyother memory chip or cartridge.

Storage media is distinct from but may be used in conjunction withtransmission media. Transmission media participates in transferringinformation between storage media. For example, transmission mediaincludes coaxial cables, copper wire and fiber optics, including thewires that comprise bus 702. Transmission media can also take the formof acoustic or light waves, such as those generated during radio-waveand infra-red data communications.

Various forms of media may be involved in carrying one or more sequencesof one or more instructions to processor 704 for execution. For example,the instructions may initially be carried on a magnetic disk or solidstate drive of a remote computer. The remote computer can load theinstructions into its dynamic memory and send the instructions over atelephone line using a modem. A modem local to computer system 700 canreceive the data on the telephone line and use an infra-red transmitterto convert the data to an infra-red signal. An infra-red detector canreceive the data carried in the infra-red signal and appropriatecircuitry can place the data on bus 702. Bus 602 carries the data tomain memory 706, from which processor 704 retrieves and executes theinstructions. The instructions received by main memory 706 mayoptionally be stored on storage device 710 either before or afterexecution by processor 704.

Computer system 700 also includes a communication interface 718 coupledto bus 702. Communication interface 718 provides a two-way datacommunication coupling to a network link 720 that is connected to alocal network 722. For example, communication interface 718 may be anintegrated services digital network (ISDN) card, cable modem, satellitemodem, or a modem to provide a data communication connection to acorresponding type of telephone line. As another example, communicationinterface 718 may be a local area network (LAN) card to provide a datacommunication connection to a compatible LAN. Wireless links may also beimplemented. In any such implementation, communication interface 718sends and receives electrical, electromagnetic or optical signals thatcarry digital data streams representing various types of information.

Network link 720 typically provides data communication through one ormore networks to other data devices. For example, network link 720 mayprovide a connection through local network 722 to a host computer 724 orto data equipment operated by an Internet Service Provider (ISP) 726.ISP 726 in turn provides data communication services through the worldwide packet data communication network now commonly referred to as the“Internet” 728. Local network 722 and Internet 728 both use electrical,electromagnetic or optical signals that carry digital data streams. Thesignals through the various networks and the signals on network link 720and through communication interface 718, which carry the digital data toand from computer system 700, are example forms of transmission media.

Computer system 700 can send messages and receive data, includingprogram code, through the network(s), network link 720 and communicationinterface 718. In the Internet example, a server 730 might transmit arequested code for an application program through Internet 728, ISP 726,local network 722 and communication interface 718.

The received code may be executed by processor 704 as it is received,and/or stored in storage device 710, or other non-volatile storage forlater execution.

In the foregoing specification, embodiments of the invention have beendescribed with reference to numerous specific details that may vary fromimplementation to implementation. The specification and drawings are,accordingly, to be regarded in an illustrative rather than a restrictivesense. The sole and exclusive indicator of the scope of the invention,and what is intended by the applicants to be the scope of the invention,is the literal and equivalent scope of the set of claims that issue fromthis application, in the specific form in which such claims issue,including any subsequent correction.

1. A method comprising: obtaining a plurality of first transaction dataitems for a proposed online credit card purchase transaction that hasbeen recommended for review; obtaining a plurality of second transactiondata items for a set of similar past online credit card purchasetransactions, wherein each member of the set has one or more transactionfeature values that are similar to transaction feature values of theplurality of first transaction data items for the proposed online creditcard purchase transaction, and a decision value specifying whether themember was accepted or rejected by a reviewer; obtaining a stored datamodel of features, feature values, transaction acceptance decisions andrejection decisions of the reviewer, wherein the stored data model isbased at least in part on the set of similar past online credit cardpurchase transactions; determining, by a processor, based on applyingthe first transaction data items to the stored data model, a likelihoodvalue of a particular decision of whether the proposed online creditcard purchase transaction would be accepted or rejected by the reviewerof the merchant; and causing the likelihood value to be displayed. 2.The method of claim 1, further comprising recording the particulardecision of whether the proposed online credit card transaction wasaccepted or rejected by the reviewer of the merchant.
 3. The method ofclaim 2, further comprising based at least part on the recordedparticular decision, updating the stored data model.
 4. The method ofclaim 1, further comprising causing to be displayed at least one or moretransaction feature values of one or more members of the set of similarpast online credit card purchase transactions.
 5. The method of claim 1,wherein the stored data model includes a hierarchical decision tree. 6.The method of claim 5, wherein the hierarchical decision tree isrepresented using XML.
 7. The method of claim 5, wherein nodes of thehierarchical decision tree represent transaction features and branchesof the hierarchical decision tree represent transaction feature values.8. The method of claim 5, further comprising removing transactionfeatures from a set of available candidate features based at least inpart on transaction rejection data values.
 9. The method of claim 5,further comprising combining transaction features from a set ofavailable candidate features based at least in part on an associationamong data values of the candidate transaction features.
 10. The methodof claim 7, wherein a transaction feature is selected as a node of thehierarchical decision tree based at least in part on a contingency tablecomprising counts of historical transaction data for the transactionfeature.
 11. The method of claim 7, wherein a transaction feature isselected as a node of the hierarchical decision tree based at least inpart on a relative entropy measure determined from the contingencytable.
 12. A non-transitory computer-readable medium carrying one ormore sequences of instructions, which when executed by one or moreprocessors, cause the one or more processors to carry out the steps of:obtaining a plurality of first transaction data items for a proposedonline credit card purchase transaction that has been recommended forreview; obtaining a plurality of second transaction data items for a setof similar past online credit card purchase transactions, wherein eachmember of the set has one or more transaction feature values that aresimilar to the transaction data items of the proposed online credit cardpurchase transaction, and a decision value specifying whether the memberwas accepted or rejected by a reviewer; obtaining a stored data model offeatures, feature values, transaction acceptance decisions and rejectiondecisions of the reviewer based at least in part on the set;determining, based on applying the first transaction data items to thestored data model, a likelihood value of a particular decision ofwhether the proposed online credit card purchase transaction would beaccepted or rejected by the reviewer of the merchant; and causing thelikelihood value to be displayed.
 13. The non-transitorycomputer-readable medium of claim 12, further comprising instructionswhich, when executed by the one or more processors, cause the one ormore processors to record the particular decision of whether theproposed online credit card transaction was accepted or rejected by thereviewer of the merchant.
 14. The non-transitory computer-readablemedium of claim 13, further comprising instructions which, when executedby the one or more processors, cause the one or more processors to,based at least part on the recorded particular decision, update thestored data model.
 15. The non-transitory computer-readable medium ofclaim 12, further comprising instructions which, when executed by theone or more processors, cause the one or more processors to display atleast one or more transaction feature values of one or more members ofthe set of similar past online credit card purchase transactions. 16.The non-transitory computer-readable medium of claim 12, wherein thestored data model includes a hierarchical decision tree.
 17. Thenon-transitory computer-readable medium of claim 16, wherein thehierarchical decision tree is represented using XML.
 18. Thenon-transitory computer-readable medium of claim 16, wherein nodes ofthe hierarchical decision tree represent transaction features andbranches of the hierarchical decision tree represent transaction featurevalues.
 19. The non-transitory computer-readable medium of claim 16,further comprising instructions which, when executed by the one or moreprocessors, cause the one or more processors to remove transactionfeatures from a set of available candidate features based at least inpart on transaction rejection data values.
 20. The non-transitorycomputer-readable medium of claim 16, further comprising instructionswhich, when executed by the one or more processors, cause the one ormore processors to combine transaction features from a set of availablecandidate features based at least in part on an association among datavalues of the candidate transaction features.
 21. The non-transitorycomputer-readable medium of claim 18, wherein a transaction feature isselected as a node of the hierarchical decision tree based at least inpart on a contingency table comprising counts of historical transactiondata for the transaction feature.
 22. The non-transitorycomputer-readable medium of claim 18, wherein a transaction feature isselected as a node of the hierarchical decision tree based at least inpart on a relative entropy measure determined from the contingencytable.